-
-
Couldn't load subscription status.
- Fork 33
Add a benchmark to test fetching of many relationships. #49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add a benchmark to test fetching of many relationships. #49
Conversation
CodSpeed Performance ReportMerging #49 will create unknown performance changesComparing Summary
Benchmarks breakdown
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #49 +/- ##
==========================================
+ Coverage 77.37% 82.13% +4.75%
==========================================
Files 10 10
Lines 725 907 +182
Branches 108 125 +17
==========================================
+ Hits 561 745 +184
+ Misses 135 129 -6
- Partials 29 33 +4 |
…sync. I left a note in the loader's __init__, but to duplicate that here: Making blocking database calls from within an async function (the resolver) has catastrophic performance implications. Not only will all resolvers be effectively serialized, any other coroutines waiting on the event loop (e.g. concurrent requests in a web server), will be blocked as well, grinding your entire service to a halt. There's no reason for us to support a foot bazooka, hence the deprecation.
This functions as a baseline, to confirm a bug that I believe I spotted which effectively serializes resolution of each relationship.
f4719fa to
eb84326
Compare
This functions as a baseline, to confirm a bug that I believe I spotted which effectively serializes resolution of each relationship.